Where did all of these changes come from?

If there is some import to a Node builtin modul (e.g. stream), Parcel autoinstalls the corresponding polyfill.

(And same goes for the two Parcel plugins listed in here, which are installed on demand. And in this case, you forgot the bump them when upgrading to "parcel": "^2.8.2")

Oh awesome! I assumed it was something like this, thanks for commenting.

BTW, shipping this is currently blocked on some significant size regressions. Webamp lazy is the simpler case to debug since it doesn't pull in some of the heavy dependencies like JSZip.

Using the bundle analyzer reporter gives a nice looking report, but it's dominated by "code from unknown sources". So my next step is to try to figure out what's contributing to this regression.

https://enchanting-khapse-0a90c1.netlify.app/webamp-lazy.html

If you happen to have any tips on how to diagnose, that'd be super helpful!

"isLibrary": true makes the default "optimize": false, because you usually don't want published libraries to be minified. But you can override that of course (I assume you want minification as they're called *.min.js?):

--- packages/webamp/package.json
+++ packages/webamp/package.json
@@ -15,7 +15,8 @@
     "webamp": {
       "source": "js/webamp.js",
       "outputFormat": "esmodule",
-      "isLibrary": true
+      "isLibrary": true,
+      "optimize": true
     },
     "webamp-browser": {
       "source": "js/webampBrowser.js",
@@ -24,7 +25,8 @@
     "webamp-lazy": {
       "source": "js/webampLazy.tsx",
       "outputFormat": "esmodule",
-      "isLibrary": true
+      "isLibrary": true,
+      "optimize": true
     },
     "demo-site": {
       "source": "demo/index.html"
@@ -36,7 +38,7 @@

Okay. It looks like the remaining difference for the lazy version is entirely attributable to the fact that I haven't yet ported my image optimization to Parcel.

I tried manually checking the optimized version of the CSS into the repo and we are now at ~3% reduction in bundle size!

Reading the Parcel docs it implies that png images are automatically optimized. It looks like that does not apply to png images that exist as data uris in CSS files (that's what my custom Webpack loader does). Is that an optimization that Parcel could/should apply? It seems in keeping with Parcel's approach of automatically applying optimizations where it can, but I also get that this is quite an edge case.

🎉

Is that an optimization that Parcel could/should apply? I also get that this is quite an edge case.

Yeah, but it should be possible to support in Parcel.

An alternative here (and this might even be preferable just from a code authoring perspective) is putting these inline PNGs into separate files and then using Parcel's feature to inline it as a data-url: https://parceljs.org/features/bundle-inlining/#inlining-as-a-data-url

Yeah, I think a "normal" app would work this way, but Webamp has built in support for loading custom "skins", which means it converts the zip file into CSS (with embedded data uris) in the browser. The way I generate the default skin CSS file is I load the custom skin and copy out the generated CSS. This means there's not a reasonable way to get those (probably hundreds) of png files as actual files on the file system.

As you saw, I raised the issue on the Parcel repo: parcel-bundler/parcel#8758 (comment)

I'll probably just keep my existing setup unless that feature looks appealing to someone to implement.

I'll see if I can fix that parcel issue you mentioned -- I'll recomment here if I get to it.